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DATA COLLECTION SYSTEM USING REMOTELY 
CONHGURABLE SCRIPTING 

TECHNICAL FIELD 

This invention relates to a digital data collection system that provides the 
ability to configure, re-configure and append software and functionality to 
remote computer installations regardless of the location or Windows ™ 
operating system of the remote computer installation. 

BACKGROUND 

Issues and questions surrounding the problem of remote data collection 
include: 

• How will specific data be retrieved? 

• When is data to be retrieved? 

• How is data to be sent? 

• When is data to be sent? 

• How can the collection system be modified remotely? 

• How are the solutions to these issues going to be controlled? 

• How can the collection system functions be customized? 

• How can new functions (i.e. Dynamic Link Libraries) be added? 

• How can old functions be replaced? 

• How can new data sources be added? 

Any solution to the above problems and issues should preferably not 
significantly impact on the operation of the remote machine from which the 
data is requested. 
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Current systems address some of fiie abovementioned needs and issues 
associated with remote data collection. A common approach is to write a 
single software application that is: 

• Hard-coded to connect to a specific data source 

• Hard-coded to connect to a temporary database 

• Hard-coded to transmit data 

Such an approach is typically taken because software is not available that is 
compatible with all the different remote systems. Different Operating 
Systems, different databases and different communication protocols make 
every solution tmique 

Subsequently, should any of tiie code embedded in the hard-coded program 
need to be changed after installation, a rewrite and complete re-compilation of 
the program and an on-site installation is typically reqvured. Oianges arise for 
many reasons but they could be as simple as a change in a directory or as 
problematic as a change in the database. 

The following imiversal needs are indicative of the shortcomings identified by 
current data collection systems: 

• Retrieval of data from multiple remote locations 

• To configure, re-configure and append installations remotely 

• Non-reliance upon and independence from a particular database 
technology or data source type used at the remote location 

It is an aim of this invention to provide a data collection system that reduces 
or eliminates some if not all of the shortcomings of the prior art or at least 
provides an alternative approach. 
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Brief Description of the Invention 

In a broad aspect of the invention is a data collection system for the aeation of 
two or more objects in a computer system at a location having a processor and 
memory, the system collects data from the computer or another computer at 
the location and transmits data to a computer at a remote location, the system 
having 

a central core system comprising a central core system object and a 
form object and a configuration file, wherein said form object creates the 
central core system object in said computer memory and which reads said 
configuration file to execute and delegate commands within the configuration 
file including the creation of data control objects, 

one or more data control objects created by said central core system, 
wherein all said objects have a common data interface for the exchange of 
commands and data between objects and a predetermined functional element 
that has access to a configuration file and one or more functional libraries, 
wherein a said data control object created includes a transmit object for 
exchanging data with said computer at said remote location. 

In a further aspect of the invention the data collection system creates an 
installer object for receiving encoded files from said computer at said remote 
location and decoding the file and installing the decoded file in a function 
library for use by one or more objects in said data collection system. 

In a yet further aspect of the invention the data collection system creates a 
timer object for storing commands to be executed by other objects a 
predetermined coimt from a reference coxmt. 
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In another aspect of the invention the data collection system creates new 
objects or updates objects using data supplied by said computer at a remote 
location. 

In a further aspect of the invention the timer object transmits to said computer 
at said remote location a signal indicating that said data collection system is 
able to transmit data to it. 

In a yet further aspect of the invention the data collection system creates a 
store object that temporarily stores data in a database and manages said 
stored data before it is transmitted to said computer at a remote location. 

In another aspect of the invention the store object bundles data in said data 
base or provides a predetermined bxmdle of data to another object or provides 
a list of bimdles or deletes old data including bimdles of data. 

In an aspect of the invention the transmit object transmits bundles of data or 
Hsts of data to said computer at a remote location. 

In another further aspect of the invention the data collection system creates a 
cormector object for collecting data from said computer or another computer 
at said location of the data collection system. 

In another aspect of the invention the data collected relates to alarms related 
to said computer or another computer at said location of the data collection 
system. 

Another aspect according to prior aspects transmit, store and connector 
objects operate whenever a predetermined period of time has elapsed or a 



wo 03/090071 



PCT/AU03/00456 



5 

predetermined amount of data has been collected or when requested by said 
computer at a remote location. 

Specific embodiments of the invention will now be described in some further 
detail with reference to and as illustrated in the accompanying figures. These 
embodiments are illustrative, and not meant to be restrictive of ihe scope of 
the invention. Suggestions and descriptions of other embodiments may be 
included but they may not be illustrated in the accompanying figures or 
alternatively features of the invention may be shown in the fig\ires but not 
described in the specification. 

Brief Description of the Figures 

Fig.l depicts a Data Collector System Object; 

Fig. 2 depicts Data Collector System Commimication Environment; 

Fig. 3 depicts synchronous coixununication between the Objects; 

Fig. 4 depicts asynchronous communication between the Objects; 

Fig. 5 depicts the Data Collector core system; 

Fig. 6 depicts the process of command execution 

Fig. 7 depicts an example of the Central Core System Object (Glue) 
executing and psissing commands at startup; 

Fig. 8 depicts a Base system; 

Fig. 9 depicts the process of establishing a heartbeat; 

Fig. 10 depicts the installation of a new object by the Installer object; 

Fig. 11 depicts the complete functional system; 

Fig, 12 depicts the retrieval of data from the remote data source and 
storage of this data into the local database; 

Fig. 13 depicts the sending of data bundles at set time intervals; and 

Fig. 14 depicts the sending of data bvmdles at set capacity levels. 
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To better understand ii\e invention, a preferred embodiment will now be 
descxibed, but it will be realized that the invention is not to be confined or 
restricted to the precise nature of this embodiment. 

Detailed Description of an Embodiment of the Invention 
The Data Collector System of the invention consists of independent, yet 
related, objects which together through the control imparted by one central 
object collects, stores and transmits data. 

The central object communicates with, and co-ordinates the activity of all 
other objects by sending and receiving XML (extended Markup Language) 
commands. The use of XML commands is preferable. The use of mvdtiple 
objects, which together perform separate functions through a common 
interface, enables the removal and addition of functionality. The use of XML 
scripting together with iiie ability to add and remove functionality enables 
remote configuration of the Data Collector System. 

The Data Collector System is comprised of Commimications Environment in 
which there is a collection of Data Collector System Objects, an XML 
Configuration File, the Common Function Library, and a Windows 
Application (which hosts the Collector Objects). Interaction with each other 
and the outside envirorunent (e.g. Remote Data Sources, Internet, Data 
Store/s) via the Data Collector System objects. 

Data Collector System Commimication Interface 

Each Data Collector System Object within the Data Collector System is 
comprised of two distinct parts depicted in Fig. 1. 

• Common Interface 

• Specialized Fimctionality 
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The Common Function Library (CFL) is accessible to all Data Collector 
System Objects and contains standard routines. Both the Common Internee 
(CI) and Specialized Functionality (SF) address the CFL yet both access a 
distincfly separate set of sections of the library, that is they do not share 
functionality within the library. The arrangement depicted is only preferable, 
as it would be quite acceptable to provide the CI and SF with separate CFLs. 

Common Interface 

The Common Interface defines a limited and fixed set of methods/properties 
that each Object knows about. These are: 

• Setup • Error 

• ShutDown • IsHealthy 

• CommandXML • Ping 

• RetumCommandXML 

The properties CommandXML and RetumCommandXML provide the 
functionality to pass XML commands between two Objects. Fig 1 illxistrates 
how the Data Collector System Object is comprised of the Common Interface 
and Specialized Functionality parts^ as well as the flow in and out of the XML 
commands- 

An XML-Command is a single XML doounent, which contains a top-level 
command and optionally a series of sub-commands. The top-level command 
with sub-commands form a to-do list. The associated Object executes the top- 
level command first, then the first sub-command is promoted to be the top- 
level command and its associated Object executes it Execution continues 
until all sub-commands are promoted and executed. 

On receipt of an XML command, the Common Interface using the Command 
XML property performs the following: 
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1. Inspects the XML to retrieve the conuxiiand and any assodated 
parameters. 

2. Calls the relevant specialized functionality that implements the 
command (passing parameters if reqvdred) * 

3. If the call returns any XML data, it adds this data to the current 
command. 

4. Retturns the (possibly updated) command to whence it came, in general 
the Central Core System Object (Que), via the RetumCommandXML 
property. 

5. Central Core System Object (Glue) promotes the first sub-command, if 
one exists, and if so repeats steps 1 to 5. 

Specialized Functionality 

The Specialized Functionality part of the Data Collector System Object, under 
instruction from ttte Conmion Interface part, performs specific operations 
such as connecting to a database to retrieve values (Connector) or to tike 
Internet to send information (Transmit), A component may have more tihan 
one specialized function. 

In this embodiment Component Object Model (COM+) is used to implement 
the functionality of this part of the component, and as such, it is comprised of 
simple procedural calls, which may or may not return data. If it does retvum 
data, it does so as valid XML. 

The Component Object Model (COM) is a way for software components to 
communicate with each other. However, COM is a particular instantiation of 
a generic object orientated communication language. COM is a binary and 
network standard that allows any two components to communicate 
regardless of what ntachine they're ruiming on (as long as the machines are 
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connected), what operating systems the machines are rtmning (as long as it 
supports COM), and what language the components are written in. COM 
further provides location transparency: it doesn't matter whether the other 
components are in-process DLLs, local EXEs, or components located on some 
other machine. 

A feature of COM is that there are three types of objects supported: in process 
(DLL), local (EXE in separate process on the same machine), and remote (DLL 
or EXE on a different machine via Distributed COM, or DCOM). Code written 
using COM components can be done without even knowing what type of 
COM object is used, so the exact same code can be used to hook up to an in- 
process, local, or remote object. COM hooks to the correct object by looking 
for the objects' Qass ID in the registry — and the registry entries tell COM 
which type or types of objects are available. COM does the rest, including 
starting processes and communicating over the network. 

Whether the language used to develop the objects is Visual Basic, Java, C++, 
Delphi, or some other COM-compatible language or some generic or specific 
object orientated commimication language, the objects written will be usable 
on a local machine or remotely without rebuilding the object or the object's 
clients. This is because of the functionality of the object orientated language 
and in this embodiment COM and DCOM. It is also possible for objects to 
run on platforms other than Windows as COM is ported to other platforms. 

Data Collector System Commimication Environment 

Any object that possesses a Common Interface may be added to the Data 
Collector System. 
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The Data Collector System Communications Environment comprises one or 
more Data Collector System Objects and respective Conunon Fxmction 
Libraries, plus a Configuration File and a Windows Executable. This is 
depicted in Fig. 2. 

bitra-system Communication Protocol 

Currently, Windows' COM+ technology is used to fodlitate communication 
between Objects. Whilst it is necessary to commtmication between Objects, it 
is not necessary to use COM+. Other protocols, such as HTTP, MSMQ or 
SMTP, iiiay be used. 

Synchronous vs. Asynchronous Communication 

Currently, conununication between the Objects is s3mchronous, tihus only the 
Object within the system may execute an XMLrCommand (containing top- 
level & sub-commands) at any moment in time. New XML-Commands can 
only begin execution when all Objects become idle. 

Despite this current implementation, communication between Objects may be 
configured so that it is asynchronous. Therefore, whilst an System Object 
cannot execute two commands simultaneously, the system as a whole will be 
able to execute commands asynchronously because distinct objects would be 
able to execute distinct commands simultaneously. Fig. 3 -Sjmchronous and 
Fig. 4 Asjmchronotis show this relationship. 

The Data Collector System Objects accommodate either synchronous or 
asynchronous communications. 

The Data Collector System preferably uses: 

• An XML scripting language to co-ordinate object activities. 
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• A central object manages the activities of independent yet related objects. 

• The Data Collector System is remotely configurable once a base system is 
installed as will be illiistrated later in this specification. 

As the arrangement of objects is completely configurable and re-configurable, 
the ntunber and type of objects present wiihin the Data Collector System at 
any one time can vary. 

Three distinct tjqjes of systems that make up a Data Collector System, each 
comprised of different collection of object are used: 

• Core system 

• Base system 

• Functional system 

Core system 

The core system is comprised of the essential objects necessary for the creation 
of all other objects. The core system alone creates the objects necessary to form 
the base system. 

Base system 

The base system supports, and is essential for, remote configuration such that 
an entire Data Collector System may be built and maintained remotely. 

Functional system 

The functional system addresses many of the issues concerning how the 
remote data is to be collected and when. 
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The advantages of remote data retrieval include: 

• Data jErom multiple remote sites can be brought together 

• System is completely remotely configurable 

• Upgrades can be implemented "on the run" 

5 

CORE SYSTEM 

The Data Collector System core system supports the following: 

• Creation of new objects to form the base system 

10 Objects 

The Core System of the Data Collector System, depicted in Figure 5, is 
comprised of the following objects: 

• Form 

• (Central Core System Object herein referred to as Glue) 
15 • Configuration File 

Form 

The Form object creates and holds Glue in memory. Form also contains a 
physical timer and sends regular time signals ("pings") to Glue. Once new 
20 objects are created. Glue in tum "pings" these objects. The ping is used for 
internal timings if required, however, is mostly ignored. The Timer object is 
the main object that utilizes the ping. 

Glue 

25 Glue binds the core system together and it in tum holds all objects of the Data 
Collector System in memory. It is responsible for creating all other objects of 
the Data Collector System and for controlling the activities of these objects 
through the use of XML commands. Glue executes commands addressed to it 
and passes commands addressed to olher objects to those objects for 
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execution. Once an object (including Glue) has executed a command, that 
command is passed back to Glue to indicate that execution is complete. 
Glue- Commands are placed in a queue 

When Glue receives a command to be executed by itself or by another object, 
5 it is placed at the end of a queue. The comn:iand at the head of the queue is 
called the current command and is the command currently being executed. 
Once execution of the current command is complete. Glue pops the next 
command off of the queue. This command becomes the current command. 

10 Glue- Commands may contain sub-commands 

When the current command contains sub-commands. Que directs the entire 
command including the sub-commands to the object to which the current 
command is addressed. This object then executes the current command and 
once completed sends the current command together with the subcommands 

15 back to Glue. 

When Glue receives an executed command back from an object. Glue checks 
to see if the command contains stib-commands. If the command does contain 
sub-commands. Glue promotes the first sub-command as the current 
20 command. The current command, together with any remaining sub- 
commands, is then sent to the relevant object for execution. These processes 
re-iterate until all sixb-commands have been executed (see Fig 6). Figure 6 
demonstrates the involvement of Glue in the process of command execution. 

25 Glue- Commands may generate oCher commands 

If the result of the execution of a command is additional commands needing 
to be executed, these additional commands are placed at Ihe end of the queue 
within Glue, and are executed once the current and preceding commands 
have been executed. 



30 



wo 03/090071 



PCT/AU03/00456 



14 

Glue- Commands may letum data 

Commands passed back to Glue may be accompanied by data. Data returned 

may be referenced by associated sub-commands through use of the following 
tag: 

5 datatype="<nameofdatatype>" 

Once the execution of a command and its sub-commands is complete, any 
data returned and held is discarded and can not be used by any other 
commands in the queue. 

10 

Glue- CreateObject command 

Glue can execute a variety of commands, however, the most important 
command to be executed is the CreateObject command. The CreateObject 
command enables Glue to create all other independent, system-related 
15 objects. Once an object is created. Glue can send commands addressed to this 
object for execution. 

Configuration File 

The configuration file stores all commands to be executed on startup and 
20 contains a list of all required initialization data. Glue reads the configuration 
file on startup. 



XML Events that occur in the Core System 
The main XML events that occur within the core system are: 
25 1. Form creates Glue 

2. Glue reads configuration file 

3. Glue executes and ddegates commands within configuration file, an 
example of which is to create objects 

<docmd dbject=^''Ghie'' anmmnd^''CreaieObject'' createobject^''X'' /> 
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Creating an object 

The CreateObject command can only be executed by Glue and is xxsed to 
create all other independent and related objects. The Configuration File 
S contains many CreateObject commands as this is read by Glue on startup and 
is necessary for the construction of the base system (see Fig:ure 7). Figure 7 
demonstrates the type of events, which occur on startup of the Data Collector 
System. 

10 BASE SYSTEM 

The Data Collector System base system supports the following: 

1. Transmission of XML data from and to the client-end 

2. Creation of new objects 

15 The Data Collector System base system, depicted in Figure 8, is comprised of 
the core system plus the following three additional objects: 

• Transmit 

• Installer 

• Timer 

20 

Transmit Object 

The Traiismit object sends and receives XML data to and from the Data 
Collector System server and as shown in Fig. 8 this is done via the Internet. 
The Transmit object includes the following functions: 

25 

1. Set up the URL addresses for the sending and receiving of data. 

2. Send data to the Data Collector System server using the Dock 
command. 
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3. Notify the Data Collector System server that Collector is 'alive' losing 
the Heartbeat command. 

4. Optionally encrypts and compresses data. 

5 On receipt of a heartbeat, the Data Collector System server sends back a 
command informing the Collector to either do nothing or to perform some 
action. The Data Collector System server can only send commands if a 
heartbeat is received. 
Installer Object 

10 The Installer object takes a data message that contains an encoded file and 
recreates it. If the file is of the type DLL (Dynamic Link library) then the 
installer will register ttie library. This functionality enables new objects to be 
created and existing objects to be upgraded. 

15 Timer Object and Command Store for timed events 

The Timer object is responsible for storing commands to be executed at a set 
frequency. By synchronizing the frequency of an event with the system clock 
it is possible to execute commands at a specific time. Timer acts as a covmter 
and sends stored commands at the appropriate times to Glue. 

20 

XML Events 

The main XML events that occur within the base system are: 

1. Setting up heartbeat UELs 

<docmd object=:Transmit" command-^SetURLs'* 
25 heanbeaturl=http://iii7wwxamnis,cmn,au/auM/col^^ 

dockurl=: ''http:/homi}mjnm$.ccnn,aiiJmhot/colkctc^ " /> 

2. Registering the heartbeat frequency 

<doand ohject^Timer" comnumd^''R£^sler*' mterval=''SO'' 
units=''Seconds"> 
30 <data types''Cotnmand"> 

Kdocmd object^Transmit" comnmid=''HgartBeat'* /> 
</data> 
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</docind> 

3, Installation of new objects 

<docmdohjecb=i"lristcilkr** cormrui^^ 
Kdata type=''DLL''>'encoded DW</data> 
5 <data type="Succes$Cotnnumd"> 

<docmd object^ "Glue " command^ "AddSystemData "> 
<docmd 6bject=^"TransTmt" comnumd="Dock" 
datatypes "Success 7> 
<data type=''Success''> 
1 0 <message vniteout^ "object AU installed 

successfully "f> 

</dat0> 
</docmd> 
</data> 

IS Kdata type="FttUweCmmand"> 

Kdocmd object^^due" comnumd^"AddSysteniData"> 
<docmd object= Transmit" commafid="Dock" 
datatype^ "Failure "/> 
<data type="Failure"> 
20 <3nessage writeout^ "object JU htstaHfidled, "/> 

</data> 
</docmd> 
</data> 
<Jdocmd> 

25 

Establishing a heartbeat 

A heartbeat sent from the Transmit object informs that the Data Collector 
System is 'alive'. The response from the central Data Collector System to a 
heartbeat is always to send a valid command, mostly a "do nothing" 
30 command. Figure 9 demonstrates the process of establishing a heartbeat and 
at step 5 A having a retttm do "Nothing" coirunand and at step 5B having a 
retxixn "Execute Command" for example Install a new .DLL file in the 
Configiiration File (common of specific to an object). 
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Installing a new object 

The installation process requires 3 main cx)mponents: 
1. XML message containing installation instructions 
5 2. Encoded DLL 

3. Success and failure commands 

Figure 10 demonstrates the installation of a new object by the Installer object. 

10 FUNCTIONAL SYSTEM 

The Data Collector System functional system as depicted in Fig. 11 supports 
the following: 

1. Retrieval of data 

2. Storing of data 
15 3. Bimdling of data 

4. Transmission of data 

Functional System Objects 

The Data Collector functional system is comprised of the base system pitas title 
20 following two objects: 

• Store 

• Connector 

Store 

25 Store is the object that manages the local database. It is necessary to collect 
information before sending it. Thus the information is temporarily stored in a 
database. Store includes functions to add items, bxmdle items, get a list of 
bundles, delete bundles, get a specific bxmdle and get the current bundle. This 
allows store to completely control the contents of the database. Store executes 
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a command based on an accumtdated size of data stored trigger or coimt 
trigger. This allows the user to configure how the database is to be managed. 

Connector 

5 The Connector object is vised to connect to the remote data sovirce. Connector 
has the capability of requesting a list of data items from the data source, 
registering groups of data items and reading those registered groups. The 
object has the capability of collecting events created by the data source. These 
events allow the Collector object to register groups of alarms, thtxs -when an 

10 alarm changes state, the Connector object is notified. 

XML Events 

The main XML events that occur within the functional system are: 

1. Connector gets data from data source 
15 <iocmdobjecb^''Cmnector'' conmand^^'G^^ 



2. 



Store adds data to local database 



3. 



<docmdobject=s''Store'' command^''AddItem'' datatype^'l^Tend'' /> 
Store bundles data 



20 



4. 



5. 



6. 



<doand object= "Store " command^ "BundleCurrentltems'*> 

Store provides specific bundle 

<docmd ohject=*'Store" command="GetBundle'' hmdidd^'*5*'/> 

Store provides list of bundles 

<docmd ohject^^Store" comnmnd=''GelBiindleList"/> 
Transmit sends bundle 



25 



<docmd object='Transimt" command="Dock" datatype="Bundle"/> 
Transmit sends list of bimdles 



7. 



8. 



<docnid object=:1'ransmir c<mmand="Dock'' datafype^''BtmdleList'*/> 
Store deletes old bimdles 

<docmd objeU^^Store" cotwmmd^''DekteOldBuTidles" oUerthan^V uriits^'Vays" /> 



30 



The events listed above occur whenever one of the following occurs: 
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1. When a set period of time has passed 

<docmd object=*Timer'' annnumd=^''Register" interDal=''50'' umts==''Minutes** 
s}/ndltHme="0O,W> 
<data type- "Command "> 
:5 <docmd object= ''Store " command- "GetBundleList''> 

<docmd object=Tran$mit'' command^''Dock'* 
datatype= "BwidleList " /> 
</djocmd> 

</daia> 

10 " </docmd> 

2. When the local database contains a certain nvunber of items or has 
reached a certain size 

<docmd dbjecl=^"Store" command^''$etTriggers*' item&xmnt=''108'' 
15 itemssize}dfs-"SOO"> 

<data type^ "Command "> 
<docmd object- "Store ' command- ''BundleCttrrentltems *> 
<docmd object=''Glue'' commands=''AddSystemData'' /> 
<docmd ohject^Transtmt" amttmnd=Vock''datatype=''Bundk''> 
20 </docmd> 
</data> 
<Jdocmd> 

3. When requested through Transmit 
25 Retrieving data at set time intervals 

The Timer object may be used to set the frequency at which specific groups of 
data are to be read and stored. 

Figure 12 demonstrates the retrieval of data from the remote data soxu-ce and 
storage of this data into the local database. 
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Sending data at set time intervals 

The Timer object may be used to set the frequency at which specific groups of 
data are to be sent. 

Figure 13 demonstrates the sending of data bvindles at set time intervals. 
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Sending data at set capacity levels 

The Store object may be used to set a capacity level at which specific groups of 
data are to be sent. 

5 Figure 14 demonstrates tihe sending of data bundles at set capacity levels. 
Altemative Transmission Methods 

The Data Collector System utilizes the HTTP protocol for the transmission of 
data as it provides tiie following advantages: 
10 1. The firewall remains open at all times allowing for the continual 
sending and receiving of information. 
2. Data can be passed in either direction. This enables the transmission of 
the remotely collected data, sending of 'Tm alive'' messages, retrieval 
of update conunands and the passing back of status messages. 
15 3. A coxmection can be either direct or made via a pro)gr server. 

4. An intermediate remote server is not reqiaired. 

5. The general user imperative for the HTTP protocol (Internet) to remain 
running at all times ensures that down time for communication 
between Data Collector System components is minimal. 

20 

Despite these advantages, the Data Collector System may be modified to 
accommodate the following altemative protocols: 

• MSMQ 

• FTP 
25 • SMTP 
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MSMQ 

MSMQ (Microsoft Message Queuing) is an effective way of communicating 
on LAN and WAN installations as it can be configured for guaranteed 
5 delivery. 

FTP 

FTP (File Transfer Protocol) enables the two-way transmission of files. 
10 SMTP 

SMTP (Simple Mail Transfer Protocol) enables the transmission of emails. 

It will be appreciated by those skilled in the art, that the invention is not 
restricted in its use to the particular application described. Neither is tiie 
1 5 present invention restricted in its preferred embodiment with regard to the 
partictdar elements and/or features described or depicted herein. It will be 
appreciated that varioxis modifications can be made without departing from 
the principles of the invention. Therefore, the invention should be 
understood to include all such modifications within its scope. 



